嗨,大家今天過得好嗎?歡迎來到鐵人賽 Day 15。
到昨天為止,我們的 n8n 後端已經可以接收前端請求,並根據用途(Switch 節點分流),安全地從自己的 PostgreSQL 資料庫撈出硬體資料。
但身為一個專業的硬體菜單系統,只看自己資料庫的死資料是不夠的。很多高階玩家會去國外 Amazon 買顯卡或 CPU,這時候「即時匯率」就非常重要;或者我們想串接 PChome/原價屋 的即時報價 API,讓 AI 推薦的菜單更精準。
如果是在傳統的後端專案裡,你要串接第三方 API,就得重新寫一套 HTTP Client、處理 Header 驗證、解析 JSON、還要寫 Try-Catch 防呆... 光想就覺得心累。今天,我們要用 n8n 裡的萬用瑞士刀——HTTP Request 節點,不寫半行 Code,把外部資料抓進來!
在 n8n 中,只要第三方服務有提供 API,你就可以用 HTTP Request 節點把它無縫接軌進你的工作流。
我們今天來實作一個情境:「在把硬體清單交給 AI 之前,先去抓取最新的 美金(USD) 轉 台幣(TWD) 即時匯率,一併提供給 AI 作為計算參考。」
Merge 節點(或是你撈完資料的 Postgres 節點)後面,新增一個 HTTP Request 節點。GET。https://api.exchangerate-api.com/v4/latest/USD
None 即可。(實務上如果你串接需要 API Key 的服務,可以在這裡輕鬆設定 Bearer Token 或 Basic Auth)。設定完後,直接點擊節點視窗右上角的 Execute Node(單獨執行此節點)。
你會看到右邊的 Output 視窗瞬間吐出了一長串精美的 JSON 格式匯率資料。沒有寫任何一行的 fetch 或 URLSession,外部資料就這樣進到我們的工作流了,是不是爽度極高?
資料抓進來了,接下來我們要在後面接一個 Edit Fields 節點,把「匯率」跟原本的「硬體清單」整理在一起。
這裡就是新手最容易踩坑的地方了。很多新手看到剛剛 HTTP 吐出來的資料有 TWD,就滿心歡喜地在 Edit Fields 裡寫下表達式:
{{ $json.TWD }}
然後一執行,發現抓到的值竟然是 [empty](空值)。
為什麼?因為外部 API 回傳的資料通常是巢狀的 (Nested)。如果你仔細看剛剛 Output 的 JSON 結構,它其實長這樣:
{
"provider": "[https://www.exchangerate-api.com](https://www.exchangerate-api.com)",
"base": "USD",
"rates": {
"EUR": 0.92,
"JPY": 149.5,
"TWD": 32.15
}
}
TWD 其實是被包在 rates 這個物件裡面的!所以正確的寫法應該是:
{{ $json.rates.TWD }}
為了避免這種肉眼看錯階層、或是拼字錯誤 (Typo) 導致的 Bug,強烈建議大家善用 n8n 的 UI 介面:
當你在設定 Edit Fields 的表達式 (Expression) 時,左邊的面板會列出上一個節點傳進來的所有資料。你只需要層層點開 rates,找到 TWD,然後把那個標籤直接「拖拉 (Drag and Drop)」到右邊的輸入框裡,n8n 就會自動幫你寫出 100% 正確的路徑!
這在串接那種結構極度複雜的外部 API(例如天氣資訊、股市報價)時,絕對是保命神招。
走到這一步,我們的工作流已經非常強大了。
現在,我們手上有:
我們只要把這三包資料,用一個 Edit Fields 節點統整成一份漂漂亮亮的 JSON Payload。這份 Payload,就是我們準備送進 AI 大腦的「最強背景知識」。
這五天下來,我們用 n8n 打造了一個堅不可摧的無程式碼後端。我們學會了接 Webhook、資料變形、安全地寫 SQL、條件分流、以及串接外部 API。
傳統後端最煩人的髒活,我們都用拖拉節點的方式解決了。
明天,這場鐵人賽將進入最核心、最刺激的第四階段!我們要正式喚醒雲端 LLM 引擎(OpenAI / Gemini),把它植入到 n8n 的工作流中,讓我們的硬體推薦系統,擁有真正的「思考與推論」能力!
我們 Day 16 見!